On Jul. 5, 1993, The New Yorker magazine published a cartoon by Peter Steiner in which two dogs are seen browsing the World Wide Web. The caption of the cartoon read, “On the Internet, nobody knows you're a dog.” This bit of satire brought into sharp relief the fact that although the Internet's popularity as a communication and information medium was due in large part to the ability of users to remain anonymous, it was that same anonymity that made e-commerce and other dealings risky.
In the physical world, many mechanisms are available to determine whether or not people are who they claim to be. Such checks did not, however, exist in the early days of the Internet. Since 1993, however, the use of digital signatures and their associated digital certificates have come to be common place; adding a measure of security to Internet-based transactions.
At its heart, a digital signature is a means for ensuring authenticity of an electronic document (e.g., an e-mail, spreadsheet, text file, etc.). Authenticity in this context means that a user knows who created the document and that it has not been altered in any way since that person created it. To ensure authenticity, digital signatures rely on certain forms of encryption, most commonly asymmetric encryption using digital certificates.
Asymmetric encryption is based on the use of two encryption keys—the values used by computer systems to enable special algorithms to turn clear text messages into unreadable, encrypted text and vice-versa. One of these keys, a private key, is known only to the user (or, more importantly, that user's computer). The user gives the second key—a public key—to anyone that wants it. Now, when anyone wants to send the user a message and ensure that only that user will be able to read it, the message is encrypted with the user's public key. Once encrypted, it can only be decrypted using the corresponding private key. Hence, so long as the user keeps his or her private key secret, the confidentiality of the message is assured. Note that the reverse of this process is also true—i.e., anything encrypted with the user's private key can only be decrypted with the corresponding public key.
Digital certificates exploit this scheme on scales needed by Web-based businesses. A digital certificate is essentially a certification (issued by a trusted third party known as a certificate authority or CA) that a particular public key is associated with an identity specified in the certificate (e.g., a web address of a server or other computer resource). That is, the CA validates the association between the owning entity and the public key.
In practice, when a user's Web browser (referred to generally as a client) first tries to contact a server for a secure transaction, the server sends its digital certificate to the client. This certificate includes (among other things) the server's public key, the server's identity, the name of the CA that signed the certificate and the signature itself (which is a mathematical hash of the certificate encrypted with the CA's private key). To validate the certificate, the client computes the certificate hash and compares the result with the hash obtained by decrypting the signature using the CA's public key (as well as checking the validity dates and identity included in the certificate against the desired server). To then validate the server, the client encrypts a message with the public key obtained from the certificate and sends it to the server. If the server can prove it can decrypt that message then it must have the associated private key and the authentication has succeeded. If desired, the server may likewise validate the client. Once the client and (optionally) the server is/are satisfied that each is the computer it claims to be, the client and server can exchange session keys (additional keys that are used to encrypt the data transfers between the computers from then on). Thus, authentication and encryption, two major security functions, are achieved using one technology. One sign that this technology has become widely adopted is the fact that many existing Web browsers and other software applications arrive preconfigured with public keys for the major commercial CAs.
The authentication process described above is embodied in the well-known secure socket layer (SSL) protocol. Originally developed by Netscape Communications, SSL has been universally accepted on the World Wide Web for authenticated and encrypted communication between clients and servers. One of the goals of SSL is to prevent so-called, “man-in-the-middle” attacks.
The “man in the middle” can be regarded as a rogue computer that attempts to insert itself in communications between a client and a server. Where secure communications are employed, the rogue attempts to intercept the legitimate keys that are passed back and forth during the SSL exchange, substitute its own keys, and make it appear to the client that it is the server, and to the server that it is the client. This is accomplished by the rogue exchanging its own keys with the client and server, allowing the rogue to establish its own session keys for use with the real server and client. Thus, the rogue not only is able to read all the data that flows between the client and the real server, but also to change the data without being detected. To counter this threat, an important part of the SSL authentication process requires that a client check that the domain name in the server's certificate corresponds to the actual domain name of the server with which the client is attempting to communicate (this is in addition to checking the validity of the certificate by performing other steps in the authentication process).
Thus, the SSL protocol has built in safeguards to prevent third party computers from snooping on communications between a client and a server. Sometimes, however, such snooping is not malicious. For example, Internet devices known as proxies are often used as “men-in-the-middle” to act as caches, content filters, virus filters, etc. Where SSL is used, however, such proxies are unable to participate in the communication stream (because the SSL protocol itself is designed to ensure they cannot). This presents a problem where there are legitimate reasons for a proxy to intercept SSL communications and it is therefore desirable to have a scheme for overcoming such difficulties.